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© A method for controlling execution of an audio video interactive program. 



© In an audio video interactive (AVI) receiver re- 
ceiving a packet stream including a directory and an 
AVI program having an associated identifier in the 
directory, a method is disclosed for controlling the 
execution of the AVI program comprises the follow- 
ing steps. First, loading the AVI program into a 



memory in response to the presence of the AVI 
program in the packet stream. Then beginning ex- 
ecution of the loaded AVI program. And then mini- 
mizing the executing AVI program when a directory 
identifying a different AVI program is detected in the 
packet stream. 
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The present invention relates to a method for 
controlling the execution of an audio video inter- 
active (AVI) executable program component. 

Interactive television systems have been pro- 
posed in which a television receiver includes a 
processor programmable by the broadcaster and 
capable of responding to data entered by the user, 
generating on-screen graphic displays overlaid 
upon the broadcast video, generating sounds com- 
bined with the broadcast audio and/or exchanging 
data with the broadcaster or other outside data 
processing service. In such a system, the broad- 
cast location includes a computer system for gen- 
erating interactive application program information, 
including executable code and data, and combining 
the interactive application program information as 
an additional component with the video and audio 
components of the associated television signal. The 
processor in the television receiver receives the 
interactive application program information from the 
broadcaster, executes the interactive application 
program represented by that information, generat- 
ing the graphics and sounds to be combined with 
the television video and audio, and processing user 
inputs received via a remote control unit. 

In a proposed AVI system, the composite AVI 
signal from the broadcaster is broadcast in the 
form of a packet data stream, including a plurality 
of time multiplexed packet services. Each packet 
service carries a different component signal of the 
composite AVI signal. For example, one service 
carries the video component, another carries the 
audio component, and another carries the inter- 
active application program information component. 
There may be still other services carrying stereo 
and SAP audio channels, and/or closed captioning 
information, etc. In addition, some packet data 
streams may include packet services carrying com- 
ponent signals for more than one AVI program. 
Each packet service has a unique service compo- 
nent identifier (SCID) associated with it and the 
packets in that packet service each include that 
service identifier. 

Further, in the proposed AVI system, one pack- 
et service carries a program guide and includes a 
predetermined service identifier. The data carried 
by the program guide packet service associates 
the components of an AVI program with the service 
identifiers of the packet services carrying those 
components. Using this data, the packet services 
carrying the components of the desired AVI pro- 
gram may be extracted from the packet stream. 

The component signals in the AVI signal pack- 
et data stream are carried by one or more trans- 
mission units, each consisting of a plurality of 
packets. A first packet in any transmission unit is a 
header packet^, and the remaining packets in the 
transmission unit are associated data packets. The 



header packet contains information about the fol- 
lowing data, and the associated data packets carry 
the data making up that portion of the component 
signal. Different transmission units may include dif- 

5 ferent numbers of data packets, and the partitioning 
of the component signals into transmission units 
may be influenced by the timing necessary to 
deliver the different component signals to the view- 
er locations at desired times, or other real time 

w considerations. 

The interactive application program information 
component consists of one or more code modules 
(containing executable code), possibly one or more 
data modules, and a directory module which in- 

75 eludes data describing the code and data modules 
making up the interactive application program com- 
ponent. These modules are continuously repeated 
in the application program data component flow. 
The modules are each uniquely identified, and are 

20 carried by transmission units, as described above, 
in which the header packet contains the identifier of 
the module and the location within that module 
where the data in the following data packets be- 
longs. The interactive application program informa- 

25 tion component also includes special signal for 
controlling the execution of the AVI application pro- 
gram. For example, one signal may instruct a cur- 
rently executing AVI application program to sus- 
pend execution; another may instruct a currently 

30 suspended AVI application program to resume ex- 
ecution; and another may instruct the currently 
executing AVI application program to cease execu- 
tion. These signals may be incorporated into signal 
packets within the AVI program component packet 

35 service. 

A processor in an AVI receiver, under the con- 
trol of the system loader, first extracts the directory 
\ module from the data flow, and utilizes the informa- 
tion contained in the directory to determine which 

40) code module is first to be executed. That code 
, ; module, called the autostart module, is then ex- 
tracted from the data flow and loaded into the 
memory. When the autostart module has been 
completely loaded into memory, the processor be- 

45 gins to execute that code module. During the 
course of its execution, that code module may 
request data from data modules identified in the 
directory module. Those data modules are then 
extracted and loaded into memory. When the mod- 

5q ule has been completely loaded into memory, the 
requesting code module is notified, and execution 
continues to process that data. It is also possible 
for one code module to chain to a subsequent one. 
In such a case, the current code module issues a 

55 . request to chain to a new code module listed in the 
directory module, and its memory space is freed. 
The requested code module is then extracted from 
the data flow, and loaded into memory. When it 
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has been completely loaded into memory, it is 
executed. Other functions are possible, and will be 
described below. 

Unlike other distributed computer systems, the 
AVI program component being received by the AVI 
receiver may change at any time. For example, an 
AVI program may be interrupted by a non-AVI 
commercial or by an AVI commercial, which, of 
course, includes a different AVI program. Or a 
viewer may change channels from one AVI pro- 
gram to another AVI program. It is necessary to 
maintain proper synchronization between the AVI 
executable code, and the sound and graphics be- 
ing generated by that code, and the audio and 
video components being received. 

In accordance with principles of the present 
invention, in an audio video interactive (AVI) re- 
ceiver receiving a packet stream including a direc- 
tory and an AVI program having an associated 
identifier in the directory, a method for controlling 
the execution of the AVI program comprises the 
following steps. First, loading the AVI program into 
a memory in response to the presence of the AVI 
program in the packet stream. Then beginning ex- 
ecution of the loaded AVI program . And then mini- 
mizing the executing AVI program when a directory 
identifying a different AVI program is detected in 
the packet stream. 
In the drawing: 
FIGURE 1 is a block diagram of a portion of an 
AVI signal decoder, incorporating the present 
invention; 

FIGURE 2 is a software structure diagram of the 
software executed by the processing unit 40 
illustrated in FIGURE 1; 

FIGURE 3 illustrates flow diagrams and memory 
layout diagrams useful in understanding the ex- 
traction of modules from the data component in 
an AVI program; 

FIGURE 4 is a diagram, partially in block form 
and partially in memory layout form also useful 
in understanding the extraction of modules from 
the data component of an AVI program; 
FIGURE 5 is a flow diagram illustrating the ini- 
tialization function of the system loader; and 
FIGURE 6 is a state transition diagram illustrat- 
ing the data stream monitoring function of the 
system loader. 
FIGURE 1 is a block diagram of a portion of an 
AVI signal decoder, incorporating the present in- 
vention. A decoder as illustrated in FIGURE 1 is 
installed in each viewer location at which it is 
desired to participate in AVI programs. In FIGURE 
1 , a transport mechanism (not shown) is coupled to 
an input terminal 5 of the decoder. Input terminal 5 
is coupled to an input terminal of a tuner 10. An 
output terminat of tuner 10 is coupled to a data 
input terminal of an AVI program component detec- 



tor 30. A data output terminal of program compo- 
nent detector 30 is coupled to a system bus 416 of 
a processing unit 40. Processing unit 40 includes a 
central processing unit (CPU) 410, a read/write 

5 memory (RAM) 412 and a read-only memory 
(ROM) 414 coupled together in a known manner 
via the system bus 416. A stream I/O adapter 408 
is bidirectionally coupled between the system bus 
416 and a control terminal of the program compo- 

w nent detector 30. 

An audio processor 418, coupled to the system 
bus 416, provides an audio signal to AVI audio 
output terminal 25, and a video processor 420, also 
coupled to the system bus 416, provides a video 

15 signal to AVI video output terminal 15. Further input 
and output facilities are provided by an I/O port 
422, coupled to a collocated local processor (not 
shown) via a bidirectional terminal 45; user I/O 
adapter 424, for receiving data from a user via an 

20 input terminal 357 and a modem 426, coupled to an 
outside computer (not shown) via a bidirectional 
terminal 55; all also coupled to the system bus 416 
in a known manner. Other equipment, e.g. math 
processors, other I/O adapters, etc., may be coup- 

25 led to system bus 416 in a known manner. In 
addition, a bus extender may be included for cou- 
pling to other equipment in enclosures external to 
the decoder enclosure. 

In operation, the transport mechanism, which, 

30 for example, may be a direct RF satellite link, a 
cable system feed or a fiberoptic link to the de- 
coder, carries a plurality of AVI signals, any one of 
which may be selected by the user for viewing. In 
a direct satellite link, for example, a plurality of AVI 

35 data streams may be frequency multiplexed on the 
transport mechanism by modulating respective RF 
carrier signals. Each RF carrier signal is rebroad- 
cast from a respective transponder in the satellite 
to the viewer location. Tuner 10 selects a desired 

40 RF modulated signal, under the control of proces- 
sor 40, in a known manner. For example, in the 
direct satellite system, the RF modulated signal 
containing the packet services carrying the compo- 
nents of the desired AVI program signal is tuned 

45 by a known RF tuner. The output of tuner 10 is a 
baseband digital packet data stream containing 
those packet services. 

CPU 410 requests desired packet services 
from the program component detector 30 by writ- 

50 ing the desired service identifiers and RAM 412 
buffer locations into appropriate service component 
identifier (SCID) and direct memory access (DMA) 
controller registers in the program component de- 
tector 30 via the stream I/O adapter 408. The 

55 program component detector 30 then monitors the 
packet data stream for the desired packet services. 
When header packets from any of the desired 
packet services are received, they are stored in a 
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predetermined header packet buffer in the RAM 
412 using known DMA write techniques, and a 
header packet interrupt is generated. When data 
packets from any of the desired packet services 
are received, they are stored in the previously 
specified buffer locations in the RAM 412 also 
using known DMA write techniques. When all the 
data packets in a transmission unit have been 
received, a data complete interrupt is generated. 
Reception of header and/or data packets from a 
packet service may be enabled and disabled under 
control of the CPU 410. See U.S. Patent Applica- 
tion: Ser. No. 232,787, PACKET VIDEO SIGNAL 
INVERSE TRANSPORT PROCESSOR MEMORY 
ADDRESS CIRCUITRY, by K.E. Bridgewater et al. 
filed 4/22/94 for a more detailed description of the 
program component detector 30. 

For example, when a new RF modulated signal 
is tuned by the tuner 10, the packet service con- 
taining the program guide is requested by the CPU 
410 by supplying the fixed program guide service 
identifier to a service identifier register in the pro- 
gram component detector 30. When the data in the 
program guide packets has been received and 
stored in memory, that data allows the CPU to 
request the packet data services for the desired 
AVI program. 

After packets in the requested packet services 
are received by the program component detector 
30, and are written via DMA into the previously 
specified buffer locations in RAM 412, the video 
processor 420 and audio processor 418 read the 
data from the RAM 412 buffer locations associated 
with their respective packet services, using known 
DMA read techniques, under control of the program 
component detector 30. Video processor 420 and 
audio processor 418 then decode the compressed 
and encoded data to produce the AVI video signal 
at output terminal 15, and the AVI audio signal at 
output terminal 25, respectively. It is also possible 
for CPU 410 to cooperate with the video processor 
420 and/or audio processor 418 in the decoding 
process. The data component packet service pack- 
ets are processed under the control of the CPU 
410 in a manner described below. 

As described above, whenever a header packet 
from a requested packet service is received by the 
program component detector 30, it is stored in a 
predetermined location in RAM 412 for that packet 
service, and a header packet interrupt signal is 
generated for the CPU 410. In response to the 
header packet interrupt signal, an interrupt handler 
is executed which analyses the contents of the 
header packet and either appropriately updates the 
RAM 412 buffer locations in the DMA registers in 
the program component detector 30 and enables 
the DMA transfer, or disables the DMA transfer if 
the transmission unit is not desired. Once the DMA 



transfer is enabled, the data in the data packets is 
then loaded into RAM 412 under DMA control. 
When the loading of the data packets is completed, 
the program component detector 30 generates a 

5 data complete interrupt signal. In response to the 
data complete interrupt signal, an interrupt handler 
is executed to perform "clean-up" functions and 
prepare for the noxt header packet. 

FIGURE 2 is a structure diagram of software 

w 200 executed by the processing unit 40 illustrated 
in FIGURE 1. FIGURE 2 illustrates the major soft- 
ware components making up the AVI processing 
multitasking operating system. In FIGURE 2, all the 
components are stored in the ROM 414, except the 

is application program, indicated by the darken area. 
The application program is carried by the data 
component of the AVI signal, is received from the 
broadcast location and is stored in RAM 412. The 
software components illustrated in FIGURE 2 repre- 

20 sent executable code and associated constant data. 
As the code executes, it may generate and access 
variable data, which is stored in the RAM 412. 

In the proposed AVI broadcast system, dif- 
ferent decoders may use CPUs using different 

25 instructions sets, e.g. from different manufacturers. 
In this system, the application program is proces- 
sor independent intermediate code. The software in 
each decoder includes a component which inter- 
prets the intermediate application code (INTER- 

30 PRETER). This enables the broadcast application 
program to be executed on decoders containing 
any type of CPU 410. That interpreter will read the 
AVI data component instructions in intermediate 
code from the RAM 412, manipulate memory, and 

as interact with the hardware through other software 
components via an application programming inter- 
face (API). This API, which is basically a list of 
subroutines available to an application program and 
the information necessary to call them, is published 

40 and may be used by the application programmer to 
access the decoder elements. 

A math library performs all the functions need- 
ed to implement integer and floating point 
arithmetic. A flow operating system controls all the 

45 drivers necessary to monitor the data component 
of the AVI signal, and process requested modules, 
as will be described in mpre detail below. A user 
interface management component handles all the 
user interaction, and utilizes a graphics library, and 

so an event manager to communicate with the user. 
The graphics library performs all the generation of 
graphic images to overlay on the received AVI 
video, and uses the math library for drawing com- 
plex curves. 

55 The different software components of the de- 

coder software communicate with other asynchro- 
nously by sending messages to each other. Each 
program component has a message queue and 
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operates by repeatedly reading the next, message 
from the queue, processing that message, possibly 
sending a message to another program compo- 
nent, and, if no more messages are pending, wait- 
ing for the next message. The event manager 
manages the communication of these messages 
among the other software components by properly 
routing the messages and maintaining the message 
queues. 

Each hardware adapter also includes an asso- 
ciated software driver. The driver performs the ac- 
tual interaction between the CPU 410 and the reg- 
isters in the associated hardware adapter via the 
system bus 416. For example, there are drivers for 
the modem 426, the external I/O port 422, the 
stream I/O adapter 408 and the user I/O 424. In 
addition, separate drivers maintain a software timer 
and operate the front panel of the decoder. These 
drivers are closely dependent on the event man- 
ager. All of the above components use common 
functions provided by a multitasking kernel. For 
example, the kernel maintains process priorities, 
active task queues, signals, semaphores, preemp- 
tive task switching clock ticks, interrupts (hardware 
and software), and process stacks. In addition, the 
kernel provides hardware initialization and initiation 
of the first system task, which is a system loader. 

At initiation, the system loader executes API 
calls to the flow operating system, which in turn 
calls the stream driver to send the appropriate data 
to the program component detector 30 via the 
stream I/O adapter 408. These API calls from the 
system loader initiate a scan of the data compo- 
nent packet service for the directory module in a 
manner described in more detail below. When the 
directory module is found, it is loaded into RAM 
412, and checked to see if all of the required 
resources to execute that program are available. If 
so, then the system loader initiates a scan of the 
AVI data component for the first module, termed an 
autostart module, which will initiate the AVI pro- 
gram. When the autostart module is located, it is 
extracted from the data component packet service 
and loaded into RAM 412. This autostart module is 
in the form of intermediate code, and is executed 
by being interpreted by the interpreter. The auto- 
start module performs the remainder of the initial- 
ization and begins execution of the AVI program. 
This program_ may possibly load other code and 
data modules/ and chain to another code module, 
all via API calls. In this manner, the system loader 
operates in the same manner as a classic UNIX® 
shell. 

In addition, the system loader continues to 
scan the data component packet service comparing 
transmitted directory modules to the current direc- 
tory module in RAM 412. If the transmitted direc- 
tory module is different than that stored in RAM 



412, it indicates that the data component packet 
service has changed, for example, such as when a 
viewer changes channels, or an interactive com- 
mercial is being broadcast In this case, a message 

5 is sent to the application program via the event 
manager using the API. In response to this mes- 
sage, the application program deallocates all its 
resources, and maintains only a minimal presence 
in the processing element 40. For example, the 

w memory used to store all code and data modules 
may be freed, and only the execution state of the 
application kept in RAM 412. When the minimiza- 
tion of the application program has completed, a 
message is sent to the system loader. 

75 The system loader then allocates the resources 

necessary to execute the AVI program represented 
by the new directory module. When a new direc- 
tory module is detected in the AVI data component 
packet service, a list of previously minimized ap- 

20 plications is searched, and if the application repre- 
sented by the new directory is present, that ap- 
plication is resumed by reloading the necessary 
code and data modules from the data component 
flow, and resuming execution from where it had 

25 previously been halted. This may happen at the 
end of an intervening interactive commercial. This 
process may be recursive, where a second AVI 
program may, itself, be interrupted by a third AVI 
program, and later reactivated. 

30 FIGURE 3 illustrates flow diagrams and mem- 

ory layout diagrams and FIGURE 4 is a more 
detailed block diagram of the program component 
detector 30 (of FIGURE 1) and a more detailed 
memory layout diagram useful in understanding the 

35 extraction of modules from the data component in 
an AVI program. In FIGURE 4, the baseband digital 
packet stream from tuner 10 (of FIGURE 1) is 
coupled to respective data input terminals of a data 
DMA controller 32 and a header packet DMA con- 

40 troller 34 within the program component detector 
30. Respective data output terminals of data DMA 
controller 32 and header packet DMA controller 34 
are coupled to the system bus 416 of the process- 
ing unit 40. The stream I/O adapter 408 is coupled 

45 between the system bus 416 and respective con- 
trol input terminals of the data DMA controller 32 
and the header packet DMA controller 34. In opera- 
tion, stream I/O adapter 408 supplies control in- 
formation, e.g. buffer location start and end ad- 

so dresses, read and write addresses, and transfer 
counts, in known manner from CPU 410 (of FIG- 
URE 1 to the data DMA controller 32 and the 
header packet DMA controller 34. Stream I/O 
adapter 408 may then enable the data DMA con- 

55 troller 32 and/or the header packet DMA controller 
34 to transfer data or header packets, respectively, 
from the packet stream to the buffer in a known 
manner, or disable such transfers, under control of 
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the CPU 410. When the data DMA controller 32 
completes a data transfer, it generates a data com- 
plete interrupt for CPU 410. When the header 
packet DMA controller 34 completes loading a 
header packet, it generates a header packet inter- 
rupt for CPU 410. 

Also in FIGURE 4. the RAM 412 is represented 
by a large block, and data structures are repre- 
sented by smaller blocks within the large block. 
The blocks in FIGURE 4 are schematic only, and 
are not meant to illustrate either absolute or relative 
locations or sizes allocated in the RAM 412 for the 
data structures. In 412, a module request queue 
322, a header packet buffer 324, a directory mod- 
ule buffer 326 and a module buffer 328 data struc- 
tures are illustrated. Fields of information within the 
data structures are illustrated as horizontal slices 
containing the name of the type of information 
contained in that field. These will be discussed in 
detail below. 

FIGURE 3 illustrates the procedure followed in 
extracting a module from the data component 
packet service and storing it in a buffer in RAM 
412. Similar procedures are followed for other mod- 
ule processing, as will be described below. In FIG- 
URE 3, actions taken in an application program (or 
the system loader) are illustrated in the left hand 
column under the heading "APPLN PROG.". In 
block 302, the application program, using the API, 
makes a request to the flow operating system to 
load a module having the identifier ID from the AVI 
program component packet service. As described 
above. API calls are basically subroutine calls to 
operating system functions. The program execution 
is, thus, transferred to the flow operating system 
(FOS). Actions taken by the FOS are illustrated in 
the next column to the right, under the heading 
"FOS." Because the request involves the loading 
of a module, in block 312 the FOS requests a 
memory allocation from the memory manager of 
sufficient size to contain the module. For example, 
if the requested module is a code or data module, 
the previously stored directory module 326 (of FIG- 
URE 4) includes a field containing the length 
(LENGTH) of the module ID. In this case a memory 
manager allocates a module memory buffer (328 of 
FIGURE 4) having a starting address START and 
an ending address END. Then, in block 314. in- 
formation describing the request, e.g. the identifier 
ID of the module, the type of request REQUEST (in 
this case a request to extract and toad a module) 
and the allocated buffer starting address START, 
and ending address END, are all stored in the entry 
in the request queue (QUEUE) 322. The header 
packet DMA controller 34 is then enabled to load 
header packets into the RAM 412, when they occur 
in the packet siream. 



If the request is for the directory module, its 
length is not known a priori In this case a rela- 
tively large memory allocation is requested. If this 
allocation turns out to be too small, the request is 

5 repeated, after requesting a larger memory alloca- 
tion, until either the directory module is loaded, or 
it is determined that there is insufficient memory to 
load it. in which case the attempt to run the AVI 
program is abandoned. 

w The FOS then immediately returns to the call- 

ing application program. The application program is 
then able to perform other processing, for example 
issuing requests for other modules, other intializa- 
tions. etc. When access to the requested module is 

/5 required, the application program, in block 304, 
may issue an API call to a wait function in the 
kernel. This function suspends the execution of the 
application program until a message indicating the 
successful loading of the requested module is re- 

20 ceived by that application program. When such a 
message is received, the application program is 
reactivated to process that message. Alternatively, 
the application program may remain active, e.g. in 
order to respond more quickly to user inputs, and 

25 periodically poll its message queue for the mes- 
sage indicating successful loading of the requested 
module, and process the message when it is re- 
ceived. 

As described above, the header packet DMA 

30 controller 34 loads header packets into a header 
packet (HDR PKT) buffer 324 (of FIGURE 4) in the 
RAM 412 previously allocated by the memory 
manager, and issues a header packet interrupt to 
the CPU 410. A portion of the processing per- 

35 formed by the header interrupt handler in the ker- 
nel is illustrated in the column headed "HEADER 
INTR" in FIGURE 3. In block 332. the identifier of 
the module which is being carried in the transmis- 
sion unit for which this is the header packet, is 

40 retrieved from a known location, ID. in the header 
packet buffer 324. In block 334. request queue 322 
is examined to determine if there is a pending 
request for this module. 

If there is a pending request for that module, 

45 then, in block 336. the data packet DMA controller 
32 in the program component detector 30 is initial- 
ized with: the module buffer 328 starting address 
START and ending address END from the request 
queue 322; a write address which is the sum of the 

so module buffer 328 starting address START and the 
transmission unit data offset OFFSET (i.e. START 
+ OFFSET); and a last write address which is 
START + OFFSET + SIZE (or alternatively, a load 
count which is the size SIZE from the header 

55 packet buffer 324 in place of the last write ad- 
dress). The data packet DMA controller 32 is then 
enabled. 
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In block 338, if this is the first header packet 
received after the load request was made, a pointer 
to the first write address, FIRST, stored in the 
request queue 322, is initialized to the write ad- 
dress of this first transmission unit (i.e. FIRST = 
START + OFFSET). In addition, a pointer to the 
expected next write address, NEXT, also stored in 
the request queue 322, is also initialized to the 
write address of the first transmission unit (i.e. 
NEXT = START + OFFSET). Other processing is 
then performed in block 338, which will be de- 
scribed in more detail below. For example, a spe- 
cial pointer to the location in the request queue 322 
of the request currently being processed. CURR 
REQ, is stored in a predetermined location (not 
shown) in RAM 412. Then, in block 339, the inter- 
rupt handler returns (339) 

The data packet DMA controller 32 initializes a 
write pointer (WP) to the previously received write 
address (START + OFFSET) and loads data from 
the following data packets in the AVI program com- 
ponent packet service into sequential locations in 
the module buffer 328 in RAM 412. When all the 
data in the transmission unit has been loaded into 
RAM 412, the data complete interrupt is generated. 
A portion of the processing performed by the data 
complete interrupt handler in the kernel is illus- 
trated in the right hand column headed "DATA 
COMPL INTR" of FIGURE 3. 

In block 342 clean-up functions related to the 
current status of the DMA transfer are executed. 
The current request pointer (CURR REQ), pre- 
viously set in the header packet interrupt handler, 
points to the entry in the request queue 322 for 
which a transmission unit has just finished loading. 
The expected next write address pointer, NEXT, in 
the current request is incremented by the value 
SIZE from the header packet buffer 324, and now 
points to the write address expected for the next 
transmission unit. If the new value of the expected 
next write address pointer, NEXT, is equal to the 
ending address. END, of the module buffer 328, it 
is reset to the starting address, START, of the 
module buffer 328. in wrap-around fashion. 

In block 344 it is determined whether the entire 
requested module has been loaded into memory. 
The value of the expected next write address pbint- 
er. NEXT, is compared to the value of the first 
loaded address, START. If they are the same, then 
the entire module has been loaded. In block 346, a 
message is sent, via the event manager, to the 
requesting application program to indicate that the 
requesting module has been completely retrieved, 
illustrated as a dashed line in FIGURE 3. In addi- 
tion, the request is removed from the request 
queue 322. If _the value of the expected next write 
address NEXT is not the same as the first loaded 
address. START, the data complete interrupt han- 



dler returns (349). and the next transmission unit 
containing data for the requested module will be 
processed by the header packet interrupt handler, 
as described above. In either event, the current 

5 request pointer (CURR REQ) is cleared. 

If some portion of a transmission unit is not 
properly received by the program component de- 
tector 30, then a subsequent header packet will be 
received before the data complete interrupt signal 

w from the preceding header packet has been gen- 
erated by the DMA circuitry in the program compo- 
nent detector 30. This, in turn, generates a subse- 
quent header packet interrupt signal before the 
preceding data complete interrupt signal can be 

75 generated. Processing in the header packet inter- 
rupt handler and the data complete interrupt han- 
dler can cooperate to identify this situation and 
provide for handling such an error. 

In the header packet interrupt handler, such 

20 processing is performed in block 338 (of FIGURE 
3), after the data packet DMA controller is enabled 
to receive the next transmission unit. For each 
header packet received, the expected next write 
address, NEXT, in the current request queue entry. 

25 previously updated by the data complete interrupt 
handler, is compared to the write address (START 
+ OFFSET) for the newly received header packet. 
If they are the same, the previous transmission unit 
was successfully received. If, however, the last 

30 ending address is not the same as the new offset, 
that means that the DMA transfer of the previous 
transmission unit did not complete successfully. In 
this case, both the first write address, FIRST, and 
the expected next write address. NEXT, are up- 

35 dated to the current write address (START + OFF- 
SET). That is, previously loaded transmission units 
are essentially discarded, and loading of the mod- 
ule is restarted with the current transmission unit. 
This form of recovering from a data missing type of 

40 error may take more time, because a transmission 
unit which was previously loaded successfully may 
result in an error when reloaded. However, by 
using this form of recovery, the tasks performed by 
the header packet interrupt handler and data com- 

45 plete interrupt handler are minimized, and only two 
pointers are needed in memory. 

As a part of the module complete message 
handling, the event handler performs an error 
checking on the received module. For example, a 

so cyclic redundancy check (CRC) code is transmitted 
as an embedded part of the module. The event 
handler calculates a CRC over the received module 
in the module buffer 328 in the RAM 412, and 
compares it to the embedded CRC. If the newly 

55 calculated CRC equals the embedded CRC. then 
the module was correctly received, otherwise an 
error occurred, and the module is reloaded, as 
described above. 
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When the requested module has been com- 
pletely loaded into memory further processing by 
the application module may continue, illustrated in 
FIGURE 3 by inference as a line from the bottom 
of the API call to the wait function 304. However, a 
separate task in the application program may be 
activated in response to the receipt of the message 
from that application program's message queue. 

The above mentioned API includes functions 
for accessing the data stream by the application 
program, via the interpreter, or by the system load- 
er. An application programmer will use the pub- 
lished API description to formulate an API call to 
access the desired data stream function. A first 
group of functions relates to the directory of mod- 
ules. A first function, DIR NEW is a request for a 

new directory. As described above, in response to 
this API function, an allocation of memory is made, 
then a request is enqueued for the loading of the 
next directory module in the data stream, then the 
API function returns. When the directory has been 
loaded, a message is sent to the requesting pro- 
gram. Another function DIR FREE, frees the 

memory space taken by the current directory. The 

function DIR SELECT indicated . which directory 

module will be used in subsequent API calls. The 

function DIR CURRENT returns a handle to the 

currently selected directory. 

The functions DIR_SPY and 

DIR_STOP__SPY are similar to the DIR__NEW 
function. In response to a DIR_SPY API call, a 
request is enqueued in the request queue for a 
directory module, but instead of loading a directory 
module and sending a message when it is loaded, 
this function sends a message whenever a direc- 
tory module is detected in the data flow (the direc- 
tory module is not loaded). In addition, the. request 
remains in the request queue until a 
DIR_ STOP__SPY API call is made. When a 

DIR STOP SPY API call is made, the request 

queue is searched for the directory spy request, 
and that entry is removed. These functions are 
useful in spying any change from the current direc- 
tory in the data stream. Finally there are API calls 
to extract information about the current directory: 

DIR IDENTIFIER, DIR REQUIREMENT and 

DIR NB MODULES. 

Because of the embedded CRC code in the 
module, any memory allocation request for loading 
a module must take this code into account. Three 
API calls are provided to handle this. The function 

MODULE ALLOC takes a module identifier as an 

argument and requests an allocation of the proper 
amount of memory to load that module, taking into 
account any CRC or other memory requirements. 

The function MODULE FREE frees the memory 

taken by a module. MODULE CHECK performs a 

CRC check of a loaded module and returns the 



result. This may be performed at any time because 
the CRC is embedded in the module as loaded in 
memory. 

Another set of API calls deals with the mod- 
5 ules, using the currently selected directory to iden- 
tify them. There are API calls to extract information 

about a module: MODULE REQUIREMENT, 

MODULE_SIZE and MODULE FLAGS. These 

enable the system to determine whether a module 
w may be loaded and/or executed. The function 

MODULE RUN is used to load an executable 

module, as described above, create a new process, 
and begin execution at the entry point of the mod- 
ule. This function is used by the system loader to 
/5 initiate AVI program execution. The function MOD- 
ULE CHAIN is used to load a subsequent execut- 
able module, end execution of the current module, 
and begin execution of the newly loaded module at 
its entry point No new process is created in this 

20 case. The function MODULE LOAD is used to 

load a module, but not start execution. As de- 
scribed above, a message is sent to the requesting 
program when the module loading has completed. 
The function MODULE__EXEC is used to create a 
25 new process and begin execution of a module, 
which was previously loaded by the MOD- 
ULE LOAD API call, at its entry point. 

The function MODULE LINK executes a new 

module using the current process, resources and 
30 variables. It allows for subroutine-like calls from 
within a module by providing a dynamic link to the 
new module. This permits AVI programs to be 
divided into smaller modules which may be dy- 
namically linked only when necessary. The MOD- 

35 ULE LINK function maintains relocation and jump 

tables. The functions MODULE_SPY and MOD- 
ULE_STOP_SPY operate similarly to the DIREC- 
TORY SPY and DIRECTORY_STOP_SPY but 

with respect to identified modules. The MOD- 
40 ULE__SPY API call inserts an entry in the request 
queue including the identifier of the module. When- 
ever a header module with the same identifier is 
detected in the data stream, a message is sent to 
the requesting program. This continues until a 
45 MODULE STOP SPY API call is made. In re- 
sponse to the MODULE_STOP_SPY API call, the 
entry containing the spying request for the iden- 
tified module is removed from the request queue. 
The MODULE_STOP_LOAD function stops any 
so module loading request currently in process and 
removes the loading request entry from the request 

queue. The functions FLOW MESSAGE and 

FLOW__STOP_MESSAGE respectively generate 
and remove a request for a message when a 
55 special signalling packet, relating to the data 
stream occurs, such as a suspended data flow or 
the end of the data flow. When such an event 
occurs, a message is sent to the requesting pro- 



8 



15 



EP 0 680 213 A2 



16 



gram. 

As described above, the system loader, per- 
forms system initialization and monitors the data 
stream to ensure that the execution of the applica- 
tion program is in synchronism with the received 
audio and video components. FIGURE 5 is a flow 
diagram illustrating the initialization function of the 
system loader. In block 52 of FIGURE 5, various 
hardware and software components of the decoder 
(of 17) are initialized. In addition, locations in the 
RAM 412 are allocated and initialized for various 
data structures. These initialization functions are 
well known, and depend upon other software com- 
ponents in the decoder. A system programmer will 
understand what hardware and software initializa- 
tions are required, what data structures are re- 
quired, and how to perform the initializations. Thus, 
this block will not be described in detail below. 

In block 54 a DIR NEW API call, described 

above, is made This API call loads the next direc- 
tory module appearing in the AVI program compo- 
nent packet service into an allocated buffer in the 
RAM 412. This API call returns to the system 
loader immediately, even though the directory may 
not be loaded into the RAM 412 until a later time. 
The system loader performs other functions and 
then, if necessary, a wait API call (not shown) until 
a message is received, via the event manager, 
indicating that the directory module has been load- 
ed. In block 56, the resources available in the 
decoder (of FIGURE 1) are compared to the data 
indicating the required resources, in the directory 
module. If the decoder has sufficient resources to 

execute the AVI program, a MODULE RUN API 

call is made to load the autostart code module, 
identified in the previously loaded directory mod- 
ule, as described above. Again, the API call . returns 
immediately, but the code module may not be 
completely loaded from the data stream until some 
later time. After the autostart code module is com- 
pletely loaded, another task is created in a known 
manner using the multitasking kernel for executing 
the AVI program, via the interpreter. 

In block 58, the system loader begins to moni- 
tor the AVI program component for execution sig- 
nals, and directory changes, and controls the ex- 
ecution of the AVI program by sending messages 
to the AVI program as described below. FIGURE 6 
is a state transition diagram illustrating the monitor- 
ing function of the system loader, and is useful in 
understanding the operation of the system loader. 
If a directory is detected in an AVI program compo- 
nent packet service, then the program that the 
viewer has selected is an interactive program. 
Once the directory has been loaded into the RAM 
412, and the autostart code module requested from 
the AVI component packet service, the AVI pro- 
gram, under the control of the system loader, en- 



ters the INACTIVE state 61. In the INACTIVE state 
61, all the resources to start the application have 
been allocated and the application may be partially 
or completely loaded, but there is no interaction 

5 with the viewer. For example, while the autostart 
module is being loaded, the AVI program remains 
in the INACTIVE state 61. In addition, even after 
the autostart module has been loaded, the viewer 
may merely be changing channels through the 

jo channel carrying the AVI program and have no 
intention of interacting with the AVI program. Or the 
viewer may just wish to observe the AVI program 
before making a decision to join the interaction. In 
all these cases it is important that the remote 

15 control acts in a normal channel changing mode 
and not in an interactive mode. This is the purpose 
of the INACTIVE state 61. In order to notify the 
viewer that the channel being watched is broad- 
casting an interactive program, a special interactive 

20 program logo or icon is overlaid upon the AV! 
video. 

In order for a viewer to actually begin to inter- 
act with the AVI program, a special key, called 
"ACTIVATE KEY" below, is provided on the remote 

25 control. When the interactive program logo or icon 
is displayed, the viewer may press the ACTIVATE 
KEY. The system loader, in response to the AC- 
TIVATE KEY press, sends an ACTIVATE message 
to the AVI program which, then, enters the ACTIVE 

30 state 63. In the ACTIVE state 63, the interpreter 
actually begins to execute the previously loaded 
AVI program at its entry point. When the autostart 
module of the AVI program begins execution, it 
allocates and initializes its own data structures in 

35 the RAM 412, loads other code and/or data mod- 
ules and controls all user actions from the remote 
control and front control panel. 

Because the AVI program controls all user in- 
teraction, it can prevent the user from changing 

40 channels or performing other normal remote control 
functions. In order to revert to normal remote con- 
trol functions, the viewer must first stop the current 
AVI program. The viewer presses the ACTIVATE 
KEY, again, to deactivate the program. In response 

45 to this key press, the system loader sends a DE- 
ACTIVATE message to the executing AVI program, 
which, then, leaves the ACTIVE state 63, and re- 
turns to the INACTIVE state 61. Again, the special 
interactive program logo or icon is displayed, in- 

so dicating that the AVI program is loaded but not 
executing. The viewer may, then, change channels 
or perform other normal remote control functions, 
or may reactivate the AVI program by pressing the 
ACTIVATE KEY again. The ACTIVATE KEY, thus. 

55 acts as a toggle to switch between the ACTIVE 
state 63 and the INACTIVE state 61 when it is 
pressed. The ACTIVATE and DEACTIVATE mes- 
sages may also be thought of as ACTIVATE TOG- 
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GLE messages, whose meaning (ACTIVATE or DE- 
ACTIVATE) depends upon the state of the AVI 
program (INACTIVE or ACTIVE, respectively) when 
the ACTIVATE KEY is pressed. 

While the AVI program is executing in the 
ACTIVE state 63, there are times when it is desired 
to suspend its execution. For example, when a 
non-interactive commercial is to be transmitted, the 
transmitted audio and video will no longer match 
the sound and graphics being generated by the 
decoder 10 (of FIGURE 1), and it is desired to 
allow the viewer to use the remote control in its 
normal manner. The application programmer, how- 
ever, cannot know in advance when such suspen- 
sions will be required. Thus, in this case, the 
broadcaster, independent of the AVI program, may 
repetitively include special signal packets (as de- 
scribed above), called suspend signal packets, in 
the AVI program component packet service. Each 
such packet contains data directing that the cur- 
rently executing AVI program is to suspend execu- 
tion. 

The system loader, via a FLOW MESSAGE 

API call, receives a message whenever such pack- 
ets are recognized in the AVI program component 
packet service. For example, when a suspend sig- 
nal packet is received, the system loader receives 
a suspend signal message, and, in response to the 
first suspend signal message, sends a SUSPEND 
message to the AVI program, which, in turn, sus- 
pends execution, entering the SUSPENDED state 
65. In the SUSPENDED state 65, execution of the 
AVI program halts in such a manner that it may be 
started again from the point where it was sus- 
pended. That is, all the resources necessary to 
execute the AVI program remain allocated, and the 
execution state of the AVI . program is stored in a 
location in the RAM 412. In addition, a second logo 
or icon, indicating that a previously executing inter- 
active program is suspended, but ready to resume 
when allowed, is overlaid over the current video 
image. 

When the interruption (e.g. non-interactive 
commercial) is over, the broadcaster stops includ- 
ing the suspend signal packets in the AVI program 
component packet service. The system loader, 
after a predetermined period of time without receiv- 
ing a suspend signal message, sends a CON- 
TINUE message to the AVI program, which, in turn, 
resumes execution from where it was previously 
suspended, entering the ACTIVE state 63, de- 
scribed above. 

An alternative embodiment of the SUS- 
PEND/CONTINUE signalling arrangement, de- 
scribed above, is for the broadcaster to include a 
single suspend signal packet in the AVI program 
component packet service when it is desired to 
suspend execution of the AVI program. The broad- 



caster, then, includes another special signal packet, 
called a continue signal packet, in the AVI program 
component packet service when it is desired to 
resume execution of the AVI program. This packet 
5 contains data directing the currently suspended 
AVI program to resume execution. The system 
loader recognizes the continue signal packet, and 
sends a CONTINUE message to the AVI program, 
which resumes execution and enters the ACTIVE 
io state 63, as described above. 

It is also possible for a viewer to stop the 
execution of a suspended AVI program. When the 
program suspended logo or icon is displayed, the 
viewer may press the ACTIVATE KEY. The system 
;s loader, responsive to this key press, sends a DE- 
ACTIVATE message to the suspended AVI pro- 
gram, which in turn, enters the INACTIVE state 61, 
described above. From the INACTIVE state 61, the 
program may only resume execution when the 
20 viewer presses the ACTIVATE KEY, causing the 
system loader to send an ACTIVATE message to 
the AVI program, which will, then, enter the AC- 
TIVE state 63. If the system loader is still receiving 
suspend signal packets, another SUSPEND mes- 
25 sage is immediately sent to the AVI program 
which, again, enters the SUSPENDED state 65. 
The INACTIVE state 61, ACTIVE state 63 and 
SUSPENDED state 65 are the states among which 
the AVI program may switch in response to mes- 
30 sages sent to it from the system loader. However; 
there are two other states which are entered under 
the direct control of the system loader. 

An AVI program can reach an end of its execu- 
tion. For example, the broadcaster may include 
35 another special signal packet, called an end execu- 
tion signal packet, in the AVI program component 
packet service. The system loader receives an end 
execution message when an end execution signal 
packet is recognized in the AVI program compo- 

40 nent packet service, via the FLOW MESSAGE 

API call. In response to the end execution mes- 
sage, the system loader sends an EXIT message 
to the AVI program. Regardless of what state the 
AVI program is in, INACTIVE 61, ACTIVE 63 or 
45 SUSPENDED 65, the AVI program responds to the 
EXIT message by deallocating all its resources, 
and removing all record of itself from the decoder 
10 (of FIGURE 1). The program is deemed to have 
entered the HALTED state 69, and disappears from 
so the decoder 10. In some cases, the program itself 
can recognize that its execution has reached an 
end, either via a user command, or by its own 
execution. When the AVI program recognizes that 
its execution has ended, it performs the same 
55 processing that it would have performed had an 
EXIT message been received, and it enters the 
HALTED state 69 on its own accord. 
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When an AVI program is in the SUSPENDED 
state, it is possible that a different interactive AVI 
program will be received on the AVI program com- 
ponent data flow. For example, if the AVI program 
was suspended for a commercial, that commercial 
may itself be an interactive program, or the user 
may have changed channels to a channel broad- 
casting a different AVI program. In both these 
cases, the new AVI program will include a directory 
module, which is different from that for the sus- 
pended AVI program. 

The system loader, via the DIR_SPY API call, 
receives a message whenever a directory is de- 
tected in the AVI program component packet ser- 
vice. The system loader compares the currently 
active directory to the just detected directory. 
When the system loader recognizes that a different 
directory is present in the AVI program component 
packet service, it begins to load the AVI program 
represented by that directory. 

First, a message is sent to the currently sus- 
pended AVI program to indicate that the program 
component packet service no longer is broadcast- 
ing its program, or that the program has' Most the 
flow.* This message is a request for the currently 
executing program to minimize itself, i.e. is a MINI- 
MIZE message. In response to the MINIMIZE mes- 
sage, the currently suspended AVI program first 
stores its current execution state and environment 
in a small block of the RAM 412 containing the 
identification of the AVI application, and a time 
duration, which will be described below. Then the 
suspended AVI program begins to deallocate is 
resources. A minimized AVI program does not in- 
clude any code, and, thus, cannot change states in 
response to messages, or restart itself. 

The system loader then loads the newly de- 
tected directory and autostart module and places 
the new AVI program in the INACTIVE state 61 
displaying the interactive program logo or icon, as 
described above. The viewer can then start and 
stop interaction with this new AVI program by 
pressing the ACTIVATE KEY, and the program 
may, itself be suspended and continued. 

The minimizing process is a recursive process. 
For example, this new AVI program, if suspended, 
may also be minimized if yet another AVI program 
is detected in the AVI program component packet 
service. In this case, another block of memory is 
allocated, and the execution state and environment 
of this AVI program, along with its identifier and a 
time duration, is stored in this memory block. Then 
the newly detected AVI program is loaded, as 
described above. The number of programs which 
may simultaneously be minimized is limited only 
by the amount of memory required to store all the 
memory blocks containing the executions states 
and environments of the minimized programs. 



If there is not enough available memory space 
to load the new directory module, or execute the 
program represented by a previously loaded direc- 
tory module, and if there are memory blocks al- 

s located representing minimized programs, the sys- 
tem loader may automatically deallocate some or 
all of the memory blocks according to an algorithm 
(such as deallocating the oldest memory block first, 
or first deallocating memory blocks marked as ex- 

w pendable by the originating application) in an at- 
tempt to derive sufficient memory space. Alter- 
natively, the system loader may present a list of 
minimized applications to the viewer, and allow the 
viewer to select some or all for deletion. Blocks 

75 representing selected minimized applications are 
then deallocated to derive sufficient memory 
space. 

In the meantime, the memory blocks containing 
the execution states and environments of previous- 

20 ly minimized AVI programs remain allocated in 
memory. As described above, there is a time dura- 
tion in each such memory block. If the time dura- 
tion in any block is exceeded, then that previously 
minimized AVI program times out In this case, that 

25 program is considered to have entered the HALT- 
ED state 69, and its block of memory containing 
the execution state and environment is deallocated, 
and all record of that previously minimized AVI 
program is lost. 

30 However, it is possible for the decoder 10 to 

again receive an AVI program component contain- 
ing the directory, code and data modules of a 
previously minimized AVI program, or for that AVI 
program to 'regain the flow/ For example, the 

35 interactive commercial may have terminated, enter- 
ing the HALTED state 69, or the viewer may have 
changed the channel back to this channel. The 
system loader begins to load the 'new' directory in 
the AVI program component packet service. When- 

40 ever a new directory is loaded, the application 
identifier is compared to the identifiers in all blocks 
containing execution state and environments cur- 
rently stored in the RAM 412. If a matching block is 
found, then the code and data modules are loaded, 

45 and the AVI program placed in the INACTIVE state 
61, but its execution state is updated to that just 
before it was minimized. When the viewer presses 
the ACTIVATE KEY, the AVI program enters the 
ACTIVE state 63, and begins execution where it 

so previously left off. In this manner, an AVI program 
may be temporarily stopped to run another AVI 
program, and then resumed, without requiring suffi- 
cient resources for both programs to remain in 
memory simultaneously. 

55 
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Claims 

1. In an audio video interactive (AVI) receiver 
receiving a packet stream including a directory 
and an AVI program having an associated 
identifier in the directory, a method for control- 
ling the execution of the AVI program char- 
acterized by the steps of: 

loading the AVI program into a memory in 
response to the presence of the AVI program 
in the packet stream; 

beginning execution of the loaded AVI pro- 
gram; and 

minimizing the executing AVI program 
when a directory identifying a different AVI 
program is detected in the packet stream. 

2. The method of claim 1, characterized in that 
the step of minimizing the executing AVI pro- 
gram comprises the steps of: 

halting execution of the AVI program; 

storing the identifier of the AVI program 
and the execution state and environment of the 
AVI program in a block of the memory; and 

unloading the AVI program from the mem- 
ory. 

3. The method of claim 2, characterized in that 
the step of loading the AVI program comprises 
the steps of: 

searching previously stored blocks of 
memory for a block containing an identifier 
matching that of the AVI program; and 

if there is a matching memory block, set- 
ting the execution state and environment of the 
loaded AVI program to that of the matching 
block of memory. 

4. The method of claim 1, characterized in that 
the packet stream further includes execution 
signals, and further comprising the step of 
halting execution, and unloading the AVI pro- 
gram from the memory in response to an end 
execution signal in the packet stream. 

5. The method of claim 1, characterized in that 
the packet stream further includes execution 
signals, and further comprising the steps of: 

suspending execution of the AVI program 
in response to a suspend execution signal in 
the packet stream; and 

continuing execution of a previously sus- 
pended AVI program in response to a continue 
execution signal in the packet stream. 

6. The method of claim 5, further characterized 
by the step of halting execution, and unloading 
the AVI program from the memory in response 



to an end execution signal in the packet 
stream. 

7. In an audio video interactive (AVI) receiver 
5 receiving a packet stream including an AVI 

program and execution signals, a method for 
controlling the execution of the AVI program 
characterized by the steps of: 

loading the AVI program into a memory in 
10 response to the presence of the AVI program . 

in the packet stream; 

beginning execution of the loaded AVI pro- 
gram; and 

halting execution, and unloading the AVI 
/s program from the memory in response to an 

end execution signal in the packet stream. 

8. The method of claim 7, characterized in that 
the end execution signal in the packet stream 

20 is represented by an end execution signal 

packet. 

9. The method of claim 7, further characterized 
by the steps of: 

25 suspending execution of the AVI program 

in response to a suspend execution signal in 
the packet stream; and 

continuing execution of a previously sus- 
pended AVI program in response to a continue 

30 execution signal in the packet stream. 

10. The method of claim 9 characterized in that 
the suspend execution signal in the packet 
stream is represented by repetitive suspend 

35 execution signal packets during a suspend 

time interval, and the continue execution signal 
is represented by no repetitive suspend execu- 
tion signal packets. 

40 11. The method of claim 9 characterized in that 
the suspend execution signal in the packet 
stream is represented by a suspend execution 
signal packet and the continue execution signal 
is represented by a continue execution signal 

45 packet. 

12. In an audio video interactive (AVI) receiver 
receiving a packet stream including an AVI 
program and execution signals, and including 
so an execution controller for controlling the ex- 

ecution of the AVI program, a method for con- 
trolling the execution of the AVI program char- 
acterized by the steps of: 

in the execution controller: 
55 loading the AVI program into a memory in 

response to the presence of the AVI program 
in the packet stream; 

sending an activate toggle message to the 
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AVI program in response to a user input; 

sending an exit message to the AVI pro- 
gram in response to an end execution signal in 
the packet stream; 

sending a suspend message to the AVI 5 
program in response to a suspend execution 
signal in the packet stream; and 

sending a continue message to the AVI 
program in response to a continue execution 
signal in the packet stream; and w 

in the AVI program: 

executing in one of: 

an inactive state, in which the AVI program 
is inactive; 

an active state, in which the AVI program is 
is executing; and 

a suspended state, in which execution of 
the AVI program is suspended; 

entering the inactive state, in response to 
the loading of the AVI program into the mem- 20 
ory; 

halting execution, and unloading the AVI 
program from the memory in response to the 
exit message; 

when in the inactive state, entering the 25 
active state in response to an activate toggle 
message; 

when in the active state: 

entering the inactive state in response to 
the activate toggle message; and 30 

entering the suspended state in response 
to a suspend message; and when in the sus- 
pended state: 

entering the active state in response to a 
continue message; and 35 

entering the inactive state in response to 
an activate toggle message. 

13. The method of claim 1 2, characterized in that: 

the suspend execution signal in the packet 40 
stream is represented by repetitive suspend 
execution signal packets during a suspend 
time interval, and the continue execution signal 
is represented by no repetitive suspend execu- 
tion signal packets; and 45 

the step of sending a suspend message in 
the execution controller comprises the step of 
sending the suspend message in response to 
a first suspend execution signal packet; and 

the step of sending a continue message in 50 
the execution controller comprises the step of 
sending a continue message after a predeter- 
mined time period in which no suspend execu- 
tion signal packets are received. 

55 

14. The method of claim 12, characterized in that: 

the suspend execution signal in the packet 
stream is represented by a suspend execution 



signal packet and the continue execution signal 
is represented by a continue execution signal 
packet; and 

the step of sending a suspend message in 
the execution controller comprises the step of 
sending the suspend message in response to 
a suspend execution signal packet; and 

the step of sending a continue message in 
the execution controller comprises the step of 
sending a continue message in response to a 
continue execution signal packet. 

15. In an audio video interactive (AVI) receiver 
selectively receiving one of a plurality of pack- 
et streams under control of a user, each pack- 
et stream including an AVI program having an 
identifier, and execution signals, the receiver 
including an execution controller for controlling 
the execution of the AVI program, a method for 
controlling the execution of the AVI program 
characterized by the steps of: 

in the execution controller: 

loading the AVI program into a memory in 
response to the presence of the AVI program 
in the selected one of the plurality of packet 
streams, storing the identifier of the loaded 
application program into a respective location 
in the memory, and searching blocks previous- 
ly stored in the memory containing identifiers 
of minimized AVI programs and if an identifier 
contained in a block matches the identifier .of 
the AVI program loaded into the memory, set- 
ting the execution state and environment of the 
newly loaded AVI program to an execution 
state and environment contained in the match- 
ing block; 

sending an activate toggle message to the 
AVI program in response to a user input; 

sending an exit message to the AVI pro- 
gram in response to an end execution signal in 
the selected one of the plurality of packet 
streams; 

sending a suspend message to the AVI 
program in response to a suspend execution 
signal in the selected one of the plurality of 
packet streams; and 

sending a continue message to the AVI 
program in response to a continue execution 
signal in the selected one of the plurality of 
packet streams; 

sending a minimize message to the AVI 
program in response to the presence of an AVI 
program in the data stream having a different 
identifier than the identifier in the respective 
location in the memory; and 

in the AVI program: 

executing in one of: 

an inactive state, in which the AVI-program 
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is inactive; 

an active state, in which the AVI program 
is executing; 

a suspended state, in which execution of 
the AVI program is suspended; and 5 

a minimized state, including the steps of: 18. 

halting execution of the AVI program; then 

storing the identifier of the AVI program 
and the execution state and environment of the 
AVI program in a block of the memory; then 10 x 

unloading the AVI 

program from the memory; 

entering the inactive state, in response to 
the loading of the AVI program into the mem- 
ory; 75 

halting execution, and unloading the AVI 
program from the memory in response to the 
exit message; 

when in the inactive state, entering the 
active state in response to an activate toggle 20 
message; 

when in the active state: 

entering the inactive state in response to 
the activate toggle message; and 

entering the suspended state in response 25 
to a suspend message; and 

when in the suspended state: 

entering the active state in response to a 
continue message; 

entering the inactive state in response to 30 
an activate toggle message; and 

entering the minimized state in response 
to the minimize message. 



the execution controller comprises the step of 
sending a continue message after a predeter- 
mined time period in which no suspend execu- 
tion signal packets are received. 

The method of claim 1 5, characterized in that: 

the suspend execution signal is represent- 
ed by a suspend execution signal packet and 
the continue execution signal is represented by 
a continue execution signal packet; and 

the step of sending a suspend message in 
the execution controller comprises the step of 
sending the suspend message in response to 
a suspend execution signal packet; and 

the step of sending a continue message in 
the execution controller comprises the step of 
sending a continue message in response to a 
continue execution signal packet. 



16. The method of claim 15, characterized in that 35 
the storing step in the step of executing in a 
minimized state in the application program fur- 
ther comprises the step of: storing a time 
duration in the block of memory, indicating a 
period of time during which the data stored in 40 
the block of the memory will remain in the 
memory and, after the time duration has ex- 
pired, removing the data stored in the block of 
memory. 

45 

17. The method of claim 15, characterized in that: 
the suspend execution signal in the selected 
one of the plurality of packet streams is repre- 
sented by repetitive suspend execution signal 
packets during a suspend time interval, and so 
the continue execution signal is represented by 

no repetitive suspend execution signal packets; 
and 

the step of sending a suspend message in 
the execution controller comprises the step of 55 
sending the suspend message in response to 
a first suspend execution signal packet; and 

the step of sending a continue message in 
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(57) In an audio video interactive (AVI) receiver 
receiving a packet stream including a directory and an 
AVI program having an associated identifier in the direc- 
tory, a method is disclosed for controlling the execution 
of the AVI program comprises the following steps. First, 
loading the AVI program into a memory in response to 
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And then minimizing the executing AVI program when a 
directory identifying a different AVI program is detected 
in the packet stream. 



DEACTIVATE 



DIRECTORY 




Printed by Rank xerox *ukj Business Services 



EPO 680 213 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 95 10 5800 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



X 
A 



C clarion of document wth indication, wfcere appropriate, 
of relevant passages 



W0-A-91 03112 (DELTA BETA PTY LTD) 7 March 
1991 

* page 3, line 7 - page 5, line 32 * 

* page 8, line 3 - page 13, line 1 * 

* page 19, 1 ine 4 - 1 ine 16 * 

* figures 1-4 * 

W0-A-92 12599 (YURT PAUL ; BROWNE H LEE 
(US)) 23 July 1992 

* page 3, line 12 - page 4, line 27 * 

* page 5, line 24 - page 16, line 5 * 

* figures 1-8 * 

IEEE TRANSACTIONS ON CONSUMER ELECTRONICS, 
vol. 38, no. 3, August 1992 
pages 319-324, 

JOSEPH ET AL -'PRIORITIZATION AND 
TRANSPORT IN THE ADTV OIGITAL SIMULCAST 
SYSTEM ' 



Relevant 
to daira 



1-4,7 
12-18 



1-18 



The present search report has been drown up for all claims 



CLASSIFICATION OF THE 
APPLICATION (IntXL6) 



H04N7/173 



TECHNICAL FIELDS 
SEARCHED (lttt.C1.6) 



H04N 



Piece «f turcb 

THE HAGUE 



11 March 1996 



Van der Zaal , R 



CATECORY OF CITED DOCUMENTS 

X : particularly relevant if taken alone 

Y : particularly relevant if combined with another 

document of the same category 
A : technological background 
O : non -written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the filing date 
D : document cited io the application 
L : document cited for other reasons 

&" member of the same patent family, corresponding 
document 



2 



